Fix detect test functions #52
Conversation
The strides are in general not constant between each ctest struct stored in memory, so we need to search specifically for the magic number. With TinyC https://repo.or.cz/tinycc.git on linux, the stride is mostly 14 ints between each entry, but sometimes 16 and 18. On other platforms it is always 14 ints. It now searches 8 ints beyond the ctest struct size, which is double of extra stride sometimes observed with TinyC. Both the current and this search is UB as it accesses memory outside the storage, but works well in practice on most platforms.
|
Pretty weird that a compiler would leave gaps in a dedicated section. Is there no way to make tinycc to fix this? Clang/GCC and all other compilers used so far were ok, so I would rather not change the simple current way.. |
…w placing main.c before, after or between test files.
|
This search is already "illegal", so it is unspecified how data are organized internally. The last update I did is quite clean and short: it jumps with one ctest struct size at the time, but if it does not see the magic number, it searches up to 8 integers further for it before it quits. Your current test already peeks memory 14 ints before and after the actual stored data, so this just searches a few more bytes outside the fixed positions when needed. |
|
If there was another magic number at the beginning of the ctest struct, you could limit how far out from the stored data you were looking when searching forward. It could still crash on "illegal memory access" in theory, but probably minimize the danger for it. So far it looks safe to peek memory around 80 bytes outside the stored table, and it is acceptable to use this trick in a development tool. |
…uter ctest entry bounds - unless compiler is TINYC on LINUX. The current seach accesses the bytes 56-60 beyond the last entry. On TINYC, it will search up to 44 byte outside if there are gaps between ctest struct entry.
|
I have some questions/remarks about the patches:
|
|
Thanks for coming back to this.
The reason why support for TinyC is important is that it compiles an order of magnitude faster than gcc/clang, (no optimizations other than simple constant folding). This makes it is perfect for testing purposes. Executing On an entirely different matter. I made my own version with a GoogleTest-like macros API. CTEST is already fairly similar to gtest, and gtest is almost the defacto testing framework in C++ (along with Catch2). I can make an PR with these API changes, and map the current conflicting API as deprecated macros if you are interested. Example: In addition, you may consider adding the parallel set of EXPECT_... macros as well. It will probably require an extra internal parameter in order to specify if test should continue or not. |
|
GoogleTest, CUnit, CppUnit etc are the reason I started ctest. Why do you need 150 Mb of test framework when 600 lines of C can do almost the same. GoogleTest has some stuff like outputting XML etc, but come on, 150 Mb?! You haven't pushed the fix for the compiler warnings yet? |
This fixes the detection of test-functions (makes it more robust).
The strides are in general not constant between each ctest struct stored in memory, so we need to search specifically for the magic number.
With TinyC https://repo.or.cz/tinycc.git on linux, the stride is mostly 14 ints between each entry, but sometimes 16 and 18. On other platforms it is always 14 ints.
It now searches 8 ints beyond the ctest struct size, which is double of extra stride sometimes observed with TinyC. Both the current and this search is UB as it accesses memory outside the storage,
but works well in practice on most platforms.